There is the increasing interest in “point-to-multipoint service” for providing the same contents to multiple users over network via one link, that is, multicast/broadcast service (hereinafter, referred to as “MBS”).
In a broadband wireless communication system based on IEEE (Institute of Electrical and Electronics Engineers) 802.16d/e or WiMAX standard, the MBS enables to provide the same data to multiple subscribers. The MBS may be largely classified into a multicast service and a broadcast service, wherein the multicast service allows the user to dynamically join and leave an IP session, and the broadcast service always distributes multicast contents without consideration for the user.
In case of the MBS, the same MBS contents should be delivered to multiple mobile stations (MSs) with the same multicast CID (hereinafter, referred to as “MCID”). Also, base stations (BS) within an MBS zone should support Macro Diversity. Thus, there should be little difference in delivery time. In this case, a reuse frequency coefficient may use “1”.
Also, a generic routing encapsulation (GRE) tunnel should be used for a data exchange between the BS and an access service network (ASN).
For a unicast transmission over IEEE 802.16e and WiMAX, a data path granularity for creation of the GRE tunnel may be the following three, that is, per-MS granularity, per-BS granularity, and per-SF (service flow) granularity.
First, the per-MS granularity creates the GRE tunnel per every MS. In this case, a GRE key is assigned through the use of 5-tuple data packet, that is, destination IP address, source IP address, source port, destination port, and protocol value; and then the GRE tunnel is created through the use of assigned GRE key. After that, the data is delivered to the BS via the GRE tunnel assigned per every MS.
Second, the per-BS granularity creates the GRE tunnel per every BS without consideration for the MS registered in the BS. Then, the data is delivered to the corresponding BS via the GRE tunnel created per every BS.
Third, the per-SF granularity creates the GRE tunnel per every service flow included in each MS. Also, the data path granularity is established together with creation of the data path. Thus, a GRE key is assigned based on the established data path granularity; and then a GRE tunnel is created through the use of assigned GRE key. Then, the data is delivered via the GRE tunnel created per every service flow included in each MS.
The aforementioned three data path granularities are for the unicast transmission. Accordingly, if the multicast data for the MBS is delivered by the aforementioned unicast transmission methods, the following problems may occur.
First, if using the per-MS granularity, the destination IP address of multicast data packet is not IP address but group address, so that it is impossible to create the GRE tunnel per every MS, that is, it is impossible to support the MBS. The GRE tunnel may be created per every MS by additionally providing an MS ID in addition to the aforementioned 5-tuples. However, it cannot ensure QoS (quality of service) for the other MBS contents requiring the other QoS parameters.
If using the per-BS granularity, it is impossible to classify the multicast data packet at R6 interface between the BS and ASN-GW. Thus, it cannot ensure QoS (quality of service) for the multicast data.
If using the per-SF granularity, the GRE tunnel is created per every service flow included in each MS. In this case, the unnecessary GRE tunnel is created for transmission of the same multicast data by the MSs registered in the multicast group. Accordingly, the unnecessary multicast data transmission occurs so that unnecessary network resources are consumed.